perm filename NOTES[EAL,HE] blob
sn#713251 filedate 1983-06-02 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00008 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Things to do for new version on 11:
C00004 00003 Stuff about FREE:
C00010 00004 Things to do:
C00013 00005 Bugs
C00017 00006 Things to watch out for:
C00018 00007 General notes
C00023 00008 Files on the UDP (ROBOT3):
C00031 ENDMK
C⊗;
Things to do for new version on 11:
Fix einit so it's a little smaller. This will save heap size.
Also maybe recompile everything to cut size of listing to 700 or so
(if you have to recompile it all).
FREE still needs to be fixed up for flushVar (commented out for now).
(See next page.)
Make it use incore overlays. This is only partially done now.
When I did it, it died at these addresses:
062326
065612
065706
065714 (most common)
065734 (also common)
Inter-overlay calls from imovrt, imove1 and imove2 were removed since
they didn't seem to be needed. Old versions (before removal) are
in *.old. IROOT is copied too.
Stuff about FREE:
Q: What was it doing before? Did I comment out the call to flushVar before,
or is this whole thing new?
A: I don't remember. I believe the call to flushvar is new, i.e. a bug fix.
∂01-Apr-83 1349 ARG flushing flushvar in free
∂31-Mar-83 1245 RV al change
Hey Ron: You added a call to flushVar in FREE (in freeStatement).
What would happen if I commented out the call to it? Anything real bad?
Rick - Well if you commented those calls to flushvar out, basically several
records would not be deallocated that should be, which wouldn't be
all that catastrophic. However maybe you could add the following
abbreviated version of flushvar to free? Also below are all of the
routines in interp that flushvar calls directly or indirectly.
Ron
procedure flushVar(oldvar: varidefp);
var v,vp,vo: varidefp; j: integer; pold: pdbp;
begin
with oldvar↑ do
begin (* flush old unused variable *)
with eCurInt↑.env↑ do
if procp then j := proc↑.level else j := block↑.level;
pold := curInt;
curInt := eCurInt; (* so we use right process to access var *)
if level <= j then
killVar(getEntry(level, offset)); (* active block flush its value *)
curInt := pold; (* restore current process *)
vtype := freevartype;
name := nil;
end;
end;
procedure killVar(e: enventryp);
var pp: pdbp; cp: cmoncbp;
begin
with e↑ do
if etype = eventtype then
begin
pp := evt↑.waitlist;
while pp <> nil do
begin pp↑.status := nullqueue; pp := pp↑.next end;
freeEvent(evt);
end
else if etype = cmontype then
repeat
if c↑.cmon↑.oncond↑.ntype = forcenode then freeEvent(c↑.evt);
freePdb(c↑.pdb); (* now it's ok to flush its pdb *)
cp := c↑.oldcmon; (* did we have several copies active? *)
relCmoncb(c); (* and also free up its cmoncb *)
c := cp;
until cp = nil;
relEentry(e);
e := nil;
end;
function envlookup (offset: integer; envhdr: envheaderp): enventryp;
var i,j,k: integer; env: environp;
begin
i := offset div 10; (* which environment block *)
j := offset mod 10; (* entry in environment block *)
if i < 5 then env := envhdr↑.env[i] (* use direct look-up *)
else begin (* run through linked list *)
env := envhdr↑.env[4];
for k := 5 to i do env := env↑.next;
end;
envlookup := env↑.vals[j];
end;
function getELev(hdr: envheaderp): integer;
begin
if hdr = sysEnv then getELev := 0
else if hdr↑.procp then getELev := hdr↑.proc↑.level
else getELev := hdr↑.block↑.level;
end;
function getEntry (level, offset: byte): enventryp;
var hdr: envheaderp;
begin
if level = 0 then hdr := sysEnv (* level zero is predefined system variables *)
else
begin
hdr := curInt↑.env; (* look up the env entry given level-offset *)
while level < getELev(hdr) do hdr := hdr↑.parent; (* move up a level *)
if level <> getELev(hdr) then (* yow!!! no environment exists!!! *)
begin
pp20L('Attempt to access no',20); pp20('n-existent environme',20);
pp20('nt - good luck! ',16); ppLine;
end;
end;
getEntry := envlookup(offset,hdr);
end;
Things to do:
It looks like, with full memory-resident overlaying, we have about
14000 bytes of memory left. Use it sparingly!
Sometime soon, combine some of the overlays, like arithn, paux1&2, etc.
When receiving a ↑C - should signal arm code with (some event flag - later)
a message. Better put this in the main loop in IMAIN - is there room?
Put more debug stuff in (↑Y).
When eProcParse is called, make sure it doesn't overflow the stack
with its local array.
---------- How to improve it ----------------------------------------
Try and find some way to increase the size of the heap. Maybe have
another task running that just stores stuff??
Maybe have one module in a resident overlay that just stores Listing array.
---------- Other stuff ----------------------------------------
Does it increase the size of a module to include external references that
are not actually used? Test this out. There's a difference between
unused routines that need to call an overlay and those for which an overlay
call already exists.
Possibly remove alloc.pas & replace with standard new & dispose.
Make a little test program to see if dispose actually works.
Call Chris Moe about latest version of Pascal-1. The latest version OSMI
supplies is 1.2K; we have 1.2F. They confirmed that 2.0 cannot deal with AL.
(we're site # 1-665).
Bugs
⊗ If you type in this program
begin
scalar i;
for i:=1 til 3 do begin
move garm to garm-4*zhat;
move garm to garm+4*zhat;
end;
end;
and run it, then stop it with control-C while it's doing a move,
it'll say "No processes currently active" and stop, pointing the cursor
to line 1; saying "@" does nothing. Saying !P makes it go into a loop
(which you can stop with ↑C).
⊗ Fix the ↑S problem. Use STEST.AL to test it.
May have to do this by trial/error since stest.pas doesn't seem to do it!
You might put in stuff to look for the ↑S and stop output until ↑Q is rec'd;
where to do this? -- in disp.mac, in the calling routines? Have a character
ast that checks? Maybe make it wait for a bit (one tick?) after it does
inserts and deletes. Shouldn't be too hard.. may need to make the amt of
time depend on how many lines - e.g. 16 ms = 1 tick per line?
⊗ Running this program
begin
move garm to garm-7*zhat
with duration=7
on |force(zhat)| >= 20*oz do
begin
stop garm
print("Got it",crlf);
end;
end;
and pushing on the arm as it goes down (to signal the force monitor)
not only does not trigger the force monitor, but when the motion completes,
it dies (ref thru nil ptr) @ PC=162164.
⊗ Sometimes I see "old line wasn't freed"; could this be the potential bug
in PP:
Look at pp.2/5p/25l - should we call relLine in here somewhere?
that I saw before?
⊗ The following is a bug:
Suppose you're entering a program into the editor:
begin
end;
↓
begin
scalar procedure sum(value scalar n);
begin
end;
end;
If you now try to insert the declaration "scalar i,j;" in front of
the procedure declaration, it says "can't have a declaration here".
If, on the other hand, you first put in the scalar decl and then,
following that, put the proc decl, it doesn't complain.
⊗ This little program doesn't get read in right - barfs at the "trans t1,..."
line. Inserting the same line into the program works, though.
begin
trans f;
frame f1,f2;
frame f3,f4;
trans t1,t2,t3; {dies here}
scalar i,j,k;
print("Hi there",crlf);
end;
Things to watch out for:
⊗ Watch out when EDIT calls FlushSomething - need to call Edit back in.
⊗ When EDIT calls FlushVar (defined edit/17p)
it creates a lot of problems! Check carefully.
General notes
To fix work file problem during TKB:
REA TKB 10 DK1:
The total size of the AL system is 342764 (decimal bytes)
This is as of about July 15, 1982
Sizes of records (as of March 24, 1983) (unchanged since last version)
Event size is 6 bytes.
Enventry size is 6 bytes.
Ident size is 8 bytes.
Token size is 8 bytes.
Resword size is 8 bytes.
String size is 12 bytes.
Node size is 12 bytes.
Cmoncb size is 12 bytes.
Vector size is 14 bytes.
Varidef size is 14 bytes.
Frame size is 16 bytes.
Envheader size is 16 bytes.
Stmnt size is 22 bytes.
Environment size: 22 bytes.
Pdb size is 28 bytes.
Trans size is 50 bytes.
Cursorp size is 8 bytes.
Files on the UDP (ROBOT3):
[AL0,RV] Contains a snapshot of AL source files May 28, 1982, before
I changed anything (from Ron's [pas,arg]).
[AL1,RV] A snapshot of the .PAS files in which I changed ↑x to xp.
[AL2,RV] Contains a snapshot of the .PAS files taken on June 9, 1982.
These are to be SRCCOM'd to later versions of the .PAS files
on [al,he] which Ron may change to correct bugs.
The version running on the 11 is made from exactly the source
code found in [al2,rv]. Compare these files on [al2,rv] to
the ones in [al,he], make the appropriate changes to the
.2 files, and (important) copy the new versions of the .pas
files on [al,he] to [al2,rv].
[AL3,RV] All the .11 files from June 29, 1982. This is the initial
editor-less version which ran on the 11 without the arm code
interface.
[AL4,RV] Contains the working version, without arm code communication,
of AL with Editor. Also some misc stuff.
[AL5,RV] This is the initial version of AL with arm code communication.
No editor..
[AL6,RV] This is the first working version of EAL with arm code
communication. There may be compile errors in the code.
In fact there are!
[AL7,RV] The last working version of EAL, version 1 Pascal.
This is almost identical to [al6,rv] but I made a copy
just to be safe (no bugs, anyway). A duplicate copy
is on ROBOT4 for extra safety.
Remember that this is the one that Ron had changed some
of the constants in ALHDR for.
[AL8,RV] The first working version-2 Pascal AL, version 2.A.
Has full resident overlays and TKB-combined overlays.
No modules have been physically combined.
Has a few bugs but otherwise seems to work.
[EAL,HE] Backed up copies of all the files on [eal,he] that made
up the version of AL on the 11 as above.